Okay, welcome back to the lecture.

There was a week break now, and what we did last week was basically the following.

First, we looked at real-world authenticated key exchange constructions.

Key exchange constructions in general.

There were a couple of things that are implemented in the real world, like TLS or the noise protocol

framework that, in contrast to TLS, does not have all the flexible modularity.

TLS is meant for you have a huge internet, nobody knows what the other computers are

configured for.

TLS' idea is that whenever one user wants to talk to another one, they will just tell the other one,

okay, I'm configured that way.

Is there any compatible way that you can communicate with me?

Then based on that negotiation, there is some way of confidential and authenticated key exchange.

In contrast to that, we have the noise protocol framework that is meant for deployment settings

in which all of the users are configured the same way.

One of the applications or one of the use cases of the noise framework is that in WhatsApp,

for example, whenever the client, the app on the phone is communicating with the server,

they will instead of using TLS, they will use the noise protocol or one of the patterns from

the noise protocol framework.

The reason is that WhatsApp can control all of its apps the same way.

They can configure what they are speaking.

Basically, all of them are speaking the same as the server.

Chrome is sometimes making similar use of that for communication between Chrome and Google.

Chrome and Cloudflare.

Similarly, very quick changes can be implemented for those type of communications, also for Firefox

and Cloudflare.

The internet is larger than just Cloudflare, Chrome, Firefox, and Google.

The internet needs to be capable of being adjustable.

For that reason, we need protocols like TLS.

We finally talked about the X3DH protocol.

The X3DH protocol is the protocol that is used for establishing messaging sessions in

Signal and in WhatsApp and so on.

This brings us to the second part of last lecture in which we talked about the idea

of ratcheted key exchange.

For short, RKE.

Today, we will dive deeper into this world of ratcheted key exchange and understand again

what the role of that is.

We again will motivate a little bit of what ratcheted key exchange is.

And we will have the first formal security definition for it.

Okay, let's directly jump into the setting.

We will repeat a couple of things on a slightly different or with a slightly different perspective

than what we did last week.

But we basically are talking about ratcheted key exchange.

And this will be the topic for this week and for next like in two weeks since next week

will not be a real lecture.

So ratcheted key exchange has the following idea.

So we have LL, we have RKE, we have RKE, we have RKE, we have RKE, we have RKE, we have

the following idea.

So we have Alice and we have Bob.

Both of them want to communicate and the idea is that they want to communicate for a long time.

So they want to have a channel that lasts for a long time